As it is generally known in networked computer systems, electronic “credentials” are data objects used in many situations for identification and/or authorization purposes. A network user may have to store and/or access various different credentials. Credentials may fall into the following categories: 1) user credentials, and 2) third party credentials. User credentials are used to prove a user's identity to remote systems. Usernames, passwords, and private keys are examples of user credentials. Third party credentials enable a user or client system to authenticate remote systems. Examples of a third party credential include public key certificates.
There are multiple accessibility requirements and restrictions for an effective credential store. Some credentials should be accessible from a variety of locations, since a user may use multiple client systems, and processes acting on the user's behalf may include programs running either on the user's client system, or on a remote server system. Additionally, credential data should be available to the user's client systems even when they are disconnected from the network. Furthermore, some sensitive credential data, such as private keys used for signing digital signatures, must be kept tightly controlled, never leaving the user's client system.
To conveniently make use of credentials, applications should be able to locate them by intended purpose. For example, when sending electronic mail (“email”), an email application needs to be able to locate the user's default signing credential, or any signing credential for a signature algorithm supported by the intended recipient. When receiving a digitally signed email message, the email application needs to determine whether the user has indicated that he trusts the certificate used to sign the received message. This leads to a requirement that applications be provided with a way to effectively search for credentials, based on the purpose for which the credentials are needed or other properties, some of which can be assigned to credentials by the user.
With regard to credential management, system administrators need to be able to specify a set of certificates that should be trusted by users whom they manage, for use in protocols such as SSL (Secure Sockets Layer) and/or S/MIME (Secure Multi-purpose Internet Mail Extensions). This type of requirement leads to a need for an administrator to be able to conveniently modify some subset of a user's credentials.
Also, some credentials, while owned by the user and considered sensitive enough to be held on the user's client machine and never released to network processes, must still be managed centrally. A user's document signing credential is an example of such a credential. The private component of the credential is extremely sensitive, and should be closely held by the user. However, the public component of the credential must be certified by a trusted third-party certificate authority, and the resulting certificate, once issued, must be re-united with the appropriate private key. In a managed environment, this process of certification and re-uniting of certificate with private key should happen without need for the user's direct interaction. This calls for an administrative process to be able to update the credential on the user's client system, in order to add the certificate to it.
Prior credential storage solutions have failed to completely and effectively address these requirements. The .NET “Passport” system provided by Microsoft® stores credential and other data on a central server for users, and uses HTTP (HyperText Transport Protocol) authentication to unlock a passport object, and to make its contents available to browser-resident code. The passports are single-user objects, and cannot be shared between users. The contents of the passport is visible to the passport server, to avoid the need for re-authenticate on every credential request, and because the passport server encrypts credentials directly for target servers rather than returning them to the client. Passport objects are not replicated to any client system, and the passport system fails to provide local credential stores, nor private network credential stores. Accordingly, the Passport system creates a single point of failure/compromise, and lacks significant desirable functionality.
The IBM® Websphere Portal Credential Vault advantageously lets users store credentials persistently. The services of this system have been limited to portlets running on a single cluster. The credential vault is available to only to server processes acting for browser clients. Client system local, and network-resident private credential stores are not provided.
The Notes ID-file in IBM® Lotus® Notes provides a local credential store, as well as roaming user support. However, the Notes ID-file offers no effective aggregation interface for multiple credential stores, or a trust policy, since it does not deal with multiple shared credential stores.
In the RSA Keon® Web Passport system, software creates an explicit “virtual smart card” on the client system, in order to avoid the use of browser features like cookies to maintain security context. However, this virtual smart card is a transient object, and does not serve as a persistent local copy of any network-resident store.
Accordingly, for the reasons stated above and others, and in view of the shortcomings of previous solutions, it would be desirable to have a new system for storing credentials that aggregates access to a variety of credential stores. The new system should allow credentials to be conveniently retrieved from the aggregated stores based on the purpose for which the credentials are needed, and/or other properties, and allow system administrators convenient access to certain types of credentials, and to portions of credentials that are otherwise kept private to the user's client system.